Release v0.7.0: Ship .sf-btn and .sf-card components - #544
Conversation
Activate the first component tranche — previously fully written but staged (commented out) in optional/components.css "until v0.8". Buttons (.sf-btn): - Refactor colour families to rule-local --sf-btn-color/-hover/-on-color so the new --outline modifier composes orthogonally with any family. - Add --outline (fills on hover), a size scale (--xs/--s/--l/--xl), and gate the .is-loading spinner behind prefers-reduced-motion. - Activate the --sf-btn-gap/-font-size/-font-weight/-min-height/-border-width knobs. Cards (.sf-card): - Activate the base component + subcomponents and the full --sf-card-* token block; add --bordered/--elevated/--interactive modifiers (interactive lift gated behind prefers-reduced-motion). Docs/tests/tooling: - Reconcile docs/components.md to the real .sf-btn name (was mis-promised as .sf-button), add HTML examples + a gradient-outline recipe; annotate the new tokens; update llm-guide and roadmap. - Add tests/button.spec.js + tests/card.spec.js (light + dark). - Configurator: add card-token controls, refresh the preview mirror note. - Bump to 0.7.0 and regenerate all token/doc/registry artifacts; refresh the token API snapshot and full-api audit token report. Closes #493, #494, #486. Advances #384. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013rU5ZV8C3RqDLbrXM41aMh
The file header still said "all definitions are commented out until v0.8", left over from before .sf-btn/.sf-card shipped in v0.7.0. Update it to reflect that those two are live; only the remaining components stay staged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013rU5ZV8C3RqDLbrXM41aMh
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughThis PR activates the previously staged ChangesComponent activation
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)Not applicable — this PR is primarily CSS token activation, generated data regeneration, documentation, and test additions without multi-component runtime interaction flow. Possibly related issues
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
PR Summary by QodoRelease v0.7.0: ship live .sf-btn and .sf-card components
AI Description
Diagram
High-Level Assessment
Files changed (28)
|
Code Review by Qodo
Context used✅ Compliance rules (platform):
12 rules 1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
optional/components.css (1)
174-198: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
.is-loadingdoesn't block pointer interaction, unlike:disabled/.is-disabled.The disabled state sets
pointer-events: none, but.sf-btn.is-loadingonly setscursor: waitand hides content — the button remains clickable while loading. This risks duplicate/concurrent submissions on non-idempotent actions (e.g. form submit handlers) if the button isn't also explicitly disabled by the consumer.🛡️ Suggested fix
.sf-btn.is-loading { cursor: wait; position: relative; + pointer-events: none; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@optional/components.css` around lines 174 - 198, The .sf-btn.is-loading state currently only changes the cursor and hides content, so it still allows clicks unlike the disabled states. Update the `.sf-btn.is-loading` rule in `components.css` to also block pointer interaction the same way `.sf-btn:disabled` and `.sf-btn.is-disabled` do, so loading buttons cannot be activated again while async work is in progress. Keep the spinner and visibility behavior in `.sf-btn.is-loading::after` unchanged.
🧹 Nitpick comments (2)
tests/button.spec.js (1)
1-182: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSolid coverage of colour families, style treatments, sizes, and states.
Tests correctly exercise the refactored rule-local custom-property model (semantic families,
--secondary/--ghost/--outlinecomposition, hover behavior). One gap: the size-scale test only comparesxs < m < xl, so it wouldn't catch a potential--l/--xlmin-height collision (see comment onoptional/components.css). Consider adding anlassertion betweenmandxlfor full scale coverage.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/button.spec.js` around lines 1 - 182, The size-scale coverage in the .sf-btn Playwright spec is incomplete because the current height ordering test only checks xs, m, and xl, so it could miss a collision between the l and xl sizes. Update the size-scale test in the button spec to include an sf-btn--l case and assert the full ordering across xs, m, l, and xl using the existing mount/computed pattern.optional/tokens.components.css (1)
52-60: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueButton tokens activation looks correct.
Values and fallbacks are consistent with the
optional/components.cssusage (e.g.--sf-btn-gap,--sf-btn-min-height). Nit:--sf-card-shadow--elevatedand--sf-card-shadow--hover(lines 24-25) resolve to the identicalvar(--sf-shadow-l)value — likely intentional (shared elevation level) but worth a comment noting they're deliberately aliased rather than accidentally duplicated.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@optional/tokens.components.css` around lines 52 - 60, The card shadow tokens in tokens.components.css are duplicated with the same var(--sf-shadow-l) value, so add an explicit comment near the relevant --sf-card-shadow--elevated and --sf-card-shadow--hover definitions to clarify they are intentionally aliased for the same elevation level. Keep the existing token names and references in optional/components.css unchanged, and make the intent obvious to future readers where those shadow tokens are declared.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@configurator/src/data/classes.generated.json`:
- Line 82: Move the `is-disabled` and `is-loading` entries out of the `.sf-btn`
group in the generated data so they appear under a generic runtime-state
grouping instead. Update the relevant catalog data in classes.generated.json to
use a framework-wide state group consistent with `core/states.css`, keeping the
button-specific `.sf-btn` group for button-only classes.
In `@docs/api-index.md`:
- Line 1036: The generated API index is misclassifying shared state helpers by
labeling `is-disabled` and `is-loading` as `.sf-btn` instead of keeping them in
their generic state groups. Update the affected entries in the docs index so the
`is-disabled` and `is-loading` rows remain grouped under INTERACTIVITY and
LOADING / ASYNC FEEDBACK, and move any button-specific context into the
description text rather than the class/group label.
In `@docs/classes.md`:
- Around line 318-319: The `.is-disabled` and `.is-loading` rows are being
listed in the wrong catalog section, which makes the source mapping
inconsistent. Update the `docs/classes.md` section that contains these state
helpers so they are either moved back under the state-class section or the
section is renamed to reflect usage-based grouping, and keep the entries aligned
with their core state-class meaning rather than `optional/components.css`.
---
Outside diff comments:
In `@optional/components.css`:
- Around line 174-198: The .sf-btn.is-loading state currently only changes the
cursor and hides content, so it still allows clicks unlike the disabled states.
Update the `.sf-btn.is-loading` rule in `components.css` to also block pointer
interaction the same way `.sf-btn:disabled` and `.sf-btn.is-disabled` do, so
loading buttons cannot be activated again while async work is in progress. Keep
the spinner and visibility behavior in `.sf-btn.is-loading::after` unchanged.
---
Nitpick comments:
In `@optional/tokens.components.css`:
- Around line 52-60: The card shadow tokens in tokens.components.css are
duplicated with the same var(--sf-shadow-l) value, so add an explicit comment
near the relevant --sf-card-shadow--elevated and --sf-card-shadow--hover
definitions to clarify they are intentionally aliased for the same elevation
level. Keep the existing token names and references in optional/components.css
unchanged, and make the intent obvious to future readers where those shadow
tokens are declared.
In `@tests/button.spec.js`:
- Around line 1-182: The size-scale coverage in the .sf-btn Playwright spec is
incomplete because the current height ordering test only checks xs, m, and xl,
so it could miss a collision between the l and xl sizes. Update the size-scale
test in the button spec to include an sf-btn--l case and assert the full
ordering across xs, m, l, and xl using the existing mount/computed pattern.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ebcb2ca4-0ffe-42d4-8df7-b55148d74871
⛔ Files ignored due to path filters (2)
configurator/package-lock.jsonis excluded by!**/package-lock.jsonpackage-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (28)
CHANGELOG.mdbadges/css-custom-data.jsonconfigurator/package.jsonconfigurator/src/components/panels/BordersPanel.svelteconfigurator/src/components/shell/PreviewPanel.svelteconfigurator/src/data/api-index.generated.jsonconfigurator/src/data/classes.generated.jsonconfigurator/src/data/token-registry.generated.jsondocs/api-index.jsondocs/api-index.mddocs/classes.mddocs/components.mddocs/llm-guide.mddocs/registry.jsondocs/roadmap.mddocs/test-coverage-6-token-reference.htmldocs/token-annotations.jsondocs/token-index.jsondocs/token-index.mddocs/tokens.mdoptional/components.cssoptional/tokens.components.csspackage.jsonreports/full-api-audit/results/tokens-report.jsontests/button.spec.jstests/card.spec.jstests/token-api.snapshot.jsontoken-registry.json
…itives A follow-up audit pass flagged a card flex/grid display toggle as missing. Verified the other three flagged gaps (link-color, icon-size, min-radius) are already covered by existing global tokens/.sf-icon, so no new card-specific knobs were needed there. The body-layout gap is better answered by composing the existing .sf-flow/.sf-cluster primitives than by adding a card-specific display switch — document that instead. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013rU5ZV8C3RqDLbrXM41aMh
- states.css: give every section comment a recognized banner form (`/* -- TITLE -- */`) so the doc generator attributes is-disabled/ is-loading to their real INTERACTIVITY/LOADING groups instead of falling through to .sf-btn's banner (the only later-scanned file with a real banner near those class names). Fixes generated-doc grouping in api-index.json/.md and the configurator's classes.generated.json. - llm-guide.md: add the missing --sf-card-media-radius token to the card token list (present in source/registry, absent from the guide). - tokens.components.css: comment clarifying that --sf-card-shadow-- elevated and --hover intentionally alias the same --sf-shadow-l step. - button.spec.js: extend the size-scale test to also assert --l sits between m and xl, closing a gap that could hide an --l/--xl collision. Verified (not changed): .sf-btn.is-loading already gets pointer-events: none from the generic .is-loading state class in core/states.css — compound-selector specificity doesn't override a property the more specific rule never sets, so no --loading state click-through exists. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013rU5ZV8C3RqDLbrXM41aMh
66aedb8 to
ee379e2
Compare
2 participants
Summary
This release ships the first tranche of SLASHED components:
.sf-btn(button) and.sf-card(card). Both components are now live in theslashed.componentslayer and included in the*-componentsandfullbundles. Remaining reserved components (badge, tag, alert, avatar, modal, skeleton, form layout helpers, table) remain staged and commented out.Key Changes
.sf-btnand.sf-cardinoptional/components.css--sf-btn-*) tooptional/tokens.components.cssfor border width, font size/weight, gap, and min-heightdocs/components.mdto reflect live component status and landing timeline.sf-btn(tests/button.spec.js) and.sf-card(tests/card.spec.js).sf-*classes (26 new)package.json, configurator, docs, badges headers)Implementation Details
--sf-btn-border-width→--sf-border-width-1)optional/tokens.components.cssand only loaded when components bundle is used.is-disabled,.is-loading) now correctly grouped under.sf-btninstead of generic categoriesnpm run buildandnpm run docsnpm run check:versionhttps://claude.ai/code/session_013rU5ZV8C3RqDLbrXM41aMh
Summary by CodeRabbit
New Features
.sf-btnand.sf-cardcomponents in version0.7.0.Bug Fixes